@lassoan Just a small suggestion regarding the category name for ImpactSynth.

The category “Image Synthesis” already exists in the Slicer Extensions Index and actually matches ImpactSynth very well.
However, for consistency with the other categories (e.g. Segmentation rather than Image Segmentation), using “Synthesis” only could be more aligned with the current naming scheme.

What do you think?

Both "Image Synthesis" and "Segmentation" sound good to me. I understand that neither of them is perfect. Our plan is to replace a single category by a list of tags, but until this infrastructure update is ready then we would like to freeze the category list and put all extensions into existing categories. I let you decide which category you choose for now, and we'll work on adding the tag system to allow more accurate characterization in the long term.

I was not suggesting introducing a new category, but commenting on naming consistency. Since existing categories use a single-noun form (e.g. Segmentation, Registration) without explicitly mentioning image, my suggestion was that Synthesis would be more consistent than Image Synthesis.

That said, since the category list is currently frozen and changes are not desired at this time, I will use Image Synthesis.

The rationale behind using "Image synthesis" was that "Synthesis" can mean so many things in different contexts, that the word by itself has almost no information content. Since we will replace single category by multiple tags soon, I would suggest not to spend time on trying to fix the category names now.

I'm reviewing what SlicerImpactSynth extension and it seems that it very heavily relies on SlicerKonfAI - so much that it ends up being really, really small, just about 100 lines of code. Since maintaining and supporting an extension requires some effort, we usually add all very tightly linked modules into a single extension. ImpactReg module could be added to the KonfAI extension, too. What was the motivation for creating separate extensions for ImpactSynth and ImpactReg?

The three extensions serve distinct and non-overlapping roles:

1. SlicerKonfAI is a general-purpose backend for executing deep learning models packaged as KonfAI Apps, supporting inference, evaluation, and uncertainty estimation.

2. ImpactSynth is a task-specific application dedicated to medical image synthesis. It exposes multiple synthesis-oriented KonfAI Apps through a focused user interface. ImpactSynth is intended to evolve along a synthesis-specific clinical roadmap, with planned support for additional synthesis-related functionality, such as radiotherapy-oriented workflows and dose-based evaluation. For this reason, it is intentionally kept separate from SlicerKonfAI, which is designed to remain a generic, task-agnostic execution backend.

3. ImpactReg is a dedicated multimodal image registration module built on top of Elastix, integrating the IMPACT similarity metric within a classical, optimization-based registration framework. It is not a KonfAI App and shares only minimal infrastructure with SlicerKonfAI, limited to GPU management and execution lifecycle handling.

To minimize duplication and maintenance overhead, shared functionality is deliberately consolidated in SlicerKonfAI. This backend provides reusable infrastructure for GPU management, logging, and execution lifecycle handling, while remaining agnostic to any specific clinical task.

As a result, ImpactReg and especially ImpactSynth are intentionally lightweight. This is a deliberate design choice and a direct consequence of centralizing generic functionality within a single, well-defined backend.

Merging these extensions would blur the separation between generic deep learning inference, synthesis-specific applications, and registration workflows, thereby reducing architectural clarity and complicating future evolution.

Keeping the extensions separate ensures clear responsibilities, independent evolution paths, and improved clinical discoverability. From a user perspective, this separation is more intuitive: synthesis, registration, and execution infrastructure are handled by distinct extensions with non-overlapping scopes, allowing users to immediately understand the purpose of each component without being exposed to unrelated functionality.

The separation between generic infrastructure and specific applications, scopes, responsibilities, evolution paths, etc. is very important and it is meant to be achieved by having multiple modules in an extension. It is valid to create a separate extension for each module, but it results in unnecessary fragmentation and more complicated maintenance and user support. The only advantage may be that you get 3 entries in the extensions index, so if people browse extension names then they probably recognize that the "ImpactReg" extension is related, but they may not realize that "KonfAI" is relevant (this may be addressed in the future by introducing tags in the extension description).

Fragmentation of code across multiple extensions is a significant burden for the extension maintainers, but not for Slicer maintainers, so if you feel confident that you want to proceed with this - and it seems you are - then it is not a problem for us.

I've noticed that you have not checked:

• Maintainers respond to issues and pull request submitted to the extension's repository.
• Maintainers respond to questions directly addressed to him/her via @mention on the Slicer Forum.

Does this mean that you would not like to make the commitment to respond to issues and pull requests and creating an account on the Slicer forum so that you can be @mentioned? That's not a problem, but then we would set your extension description to be Tier 2.

Yes, I do prefer to keep these components as separate extensions in order to clearly reflect three distinct categories. There is no redundant code across the three extensions, as shared functionality is centralized, which keeps the maintenance overhead minimal. I am also comfortable keeping these extensions up to date with ongoing Slicer developments.

Regarding the checkboxes, I was not initially sure whether checking these boxes was meant to indicate that I already respond to issues and forum questions, or whether it represented a commitment to do so. I do intend to take on this responsibility, and I have now checked both items to reflect my commitment to responding to issues, pull requests, and questions addressed to me on the Slicer Forum.